add controlflow handling to Layout2qDistance transpiler pass #8733
Conversation
|
Thank you for opening a new pull request. Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient. While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone. One or more of the the following people are requested to review this:
|
Pull Request Test Coverage Report for Build 3040745492
💛 - Coveralls |
There was a problem hiding this comment.
When I needed to make depth and size "estimates" for the optimisation-loop fixed-point-condition analysis passes (#8763), I treated while loops as having a single loop - for the purposes of what's being tested, it's sufficient.
This pass is a bit of a weird one. It's only used to evaluate if a layout is perfect or not - we don't need any sort of realistic estimate at all, just a "zero or not". The documentation of the class just says that the output number is the "score", rather than representing something physical, so it doesn't matter if it's not perfect. It still does feel a bit weird that it may return nan in this form; I feel like if we do commit to returning a number, we always ought to return a number.
After writing this, I'm really wondering if it would be more appropriate for us simply to swap the O1 "perfect layout" condition over to use CheckMap instead. That's more logically the operation we're trying to perform here, and it's slightly more sound anyway - this pass can't really be made Target-aware in the same way (because the concept of the distance matrix isn't clear once there's 3q+ gates or cx isn't the only 2q operation), so currently O1 is technically inconsistent with itself pre- and post-routing.
Perhaps we could carve the CheckMap changes out of #8418, swap the layout check to that, and deprecate this PR?
cc: @mtreinish, @kdk for your opinions, since I don't know the history behind the choice in the presets. Looks like it was added in #3657, and the initial Layout2qDistance was in #3321, and neither has substantially changed since those PRs.
|
I tend to agree, the 2q distance does seem like overkill for determining that a trivial layout is perfect. |
|
On its own this pass proposes to score the quality of a layout in a reasonable way. Whether or not other passes use this analysis is a somewhat separate issue, although it doesn't seem like anything in terra currently use this information in a way that can't be replaced by In the case of level1 it seems fine to replace this pass with |
Summary
This pr adds controlflow handling to the Layout2qDistance transpiler pass.
Details and comments
This implementation adds an init parameter
weight_loopsto indicate whether the number of blocks/loops should contribute to the overall 2q layout score. If True for while loops, NaN is returned.